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A  Reasonable  View  Update  Translator 
That  Preserves  No  Complement 
Arthur  M.  Keller 

Computer  Science  Dept.,  Stanford  University 


ABSTRACT.  A  shared  database  encompasses  data  of 
interest  to  a  variety  of  users.  A  database  view  provides 
a  class  of  users  with  an  image  of  a  portion  of  the  data 
presented  according  to  the  needs  of  these  users.  The 
ability  to  translate  updates  specified  against  the  view 
into  updates  specified  against  the  database  is  necessary 
to  allow  more  effective  use  of  views.  Since  a  user  ac¬ 
cessing  the  database  through  a  view  has  limited  knowl¬ 
edge  of  the  entire  domain  of  the  database,  it  is  neces¬ 
sary  to  limit  the  effect  on  others  of  a  particular  user’s 
view  update.  Furthermore,  there  may  be  many  ways 
to  translate  a  particular  view  update  into  database  up¬ 
dates.  Bancilhon  and  Spyratos  propose  the  notion  of 
a  constant  complementary  view,  which  partially  solves 
the  problem  of  view  updates  by  addressing  these  two 
issues.  We  present  a  reasonable  view  update  translator 
that  does  not  preserve  any  complement.  This  illustrates 
the  overly  restrictive  consequences  of  the  requirement 
that  a  complement  remain  constant. 

KEYWORDS.  Relational  databases,  database  theory, 
complementary  mappings,  view  update. 

CR  Categories.  H.2.1,  H.i.i,  E.4. 

1.  Introduction 

We  wish  to  control  the  effect  of  the  actions  of  users  of 
shared  databases  on  other  users  without  unnecessarily 
restricting  these  actions.  Views  provide  an  image  of  a 
portion  of  the  database  according  to  the  user’s  needs 
[Stonebraker  75].  The  problem  of  translating  an  up¬ 
date  specified  against  the  view  into  an  update  specified 
against  the  database  has  been  explored  [Bancilhon  81, 
Dayal  82,  Keller  82]  but  not  completely  solved.  One 
consideration  is  that  various  alternatives  may  exist,  all 
of  which  implement  the  request  desired  by  the  user  from 
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tained  in  this  document  are  those  of  the  authors  and  should  not 
be  interpreted  as  representative  of  the  official  policies  of  DARPA 
or  the  US  Government. 

Author’s  address:  Computer  Science  Department,  Stanford  Uni¬ 
versity,  Stanford,  CA  04305- 2088. 


the  user’s  point  of  view.  However,  some  of  these  trans¬ 
lations  may  make  unnecessary  changes  to  others  part  of 
the  database  that  do  not  affect  the  view. 

Bancilhon  and  Spyratos  [81]  propose  that  a  com¬ 
plementary  view— one  that  contains  all  the  information 
in  the  database  not  contained  in  the  user’s  view— be 
held  constant  in  order  to  preclude  these  “side  effects” 
that  may  affect  other  users.  This  approach  provides 
than  any  translation  from  a  view  update  to  a  database 
update  must  be  unique.  Unfortunately,  this  rules  out 
many  reasonable  translations  that  are  otherwise  accept¬ 
able.  Wc  present  a  particular  view  update  translator 
that  is  quite  reasonable,  but  that  does  not  preserve  any 
complement. 

2.  Definitions 

We  assume  the  reader  is  familiar  with  relational  data¬ 
base  theory  as  presented  by  Ullman  [82]  and  Maier  [83]. 
Prior  work  on  complements  [Bancilhon  81,  Keller  84] 
will  also  provide  useful  background. 

DEFINITION  [Bancilhon  81].  Let  /  and  g  be  two  func¬ 
tions  whose  domain  is  D.  Then  /  and  g  are  comple¬ 
mentary  mappings  if 

[V*,y  6  D}[(x  /  p)  A  /(*)  =  /( y)  —  3(1)  yt  j/(y)]. 

COROLLARY.  Given  a  database  D  and  a  view  v  and  a 
complementary  view  c,  there  is  at  most  one  database 
state  that  corresponds  to  a  desired  view  state  (range  of 
v)  for  a  fixed  view  state  (range  of  c). 

The  consequence  of  this  corollary  is  that  a  view  up¬ 
date  translator  that  holds  a  complement  constant  has  at 
most  one  translation.  There  are,  however,  view  update 
translators  that  have  at  most  one  translation  that  do 
not  hold  any  complement  constant.  In  the  next  section, 
we  will  a  reasonable  one. 

3.  A  View  Update  Translator 

Consider  the  relation  AD,  with  two  attributes  A  and  B, 
and  the  functional  dependency  A  — *  B.  Let  the  domain 
of  A  contain  at  least  one  element,  al,  and  the  domain  of 
B  contain  at  least  two  elements,  bl  and  b2.  We  define 
the  view  V  to  select  all  tuples  from  AB  where  B  —  bl. 

We  shall  define  a  view  update  translator  that  ac¬ 
cepts  all  single  tuple  updates  valid  in  the  view. 
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Insert  tuple  (a,  b):  If  there  exists  a  tuple  (a,  y),  then 
replace  (a,  y)  with  (a,  b),  otherwise  insert  (a,  b). 
Delete  tuple  (a,  b):  Delete  tuple  (a,  b)  from  the  un¬ 
derlying  database. 

Replace  tuple  (a,  b)  by  tuple  (c,  d):  Perform  transla¬ 
tion  for  deleting  (a,  b)  followed  by  translation  for  in¬ 
serting  (c,  d). 

Let  us  consider  the  translations  of  the  insertion  of 
the  tuple  (al,  bl)  starting  with  two  different  database 
states  using  this  view  update  translator. 

Initial  database  state  1: 

A 

D 

al  b2 

Initial  view  state  1: 

A 
B 

empty  relation 

Result  database  state  1: 

A 
B 

al  bl 

Result  view  state  1: 

A 
B 

al  bl 

Initial  database  state  2: 

A 
B 

empty  relation 

Initial  view  state  2 
A 
B 

empty  relation 

Result  database  state  2: 

A 
B 

al  bl 

Result  view  state  2: 

A 
B 

al  bl 

We  observe  that  initial  view  state  1  and  initial  view 
state  2  are  the  same,  yet  initial  database  state  1  and 
initial  database  state  2  are  different.  Therefore,  any 
complement  view  must  have  different  values  for  initial 
database  state  1  and  initial  database  state  2.  However, 
the  result  database  states  are  the  same.  Thus,  the  result 


complement  states  must  be  the  same.  Consequently,  the 
complement  cannot  be  remain  constant. 

If  we  wanted  to  hold  constant  a  complement,  we 
could,  for  example,  choose  the  complement  formed  by 
selecting  all  tuples  with  B  /  bl.  This  would  preclude 
accepting  the  insertion  request  above  for  database  state 
1.  We  could  define  another  translator  that  holds  an¬ 
other  complement  constant,  but  it  could  not  implement 
all  of  these  requests  in  the  same  way. 

4.  Conclusion 

While  view  complements  provide  insight  into  the  pro¬ 
cess  of  view  update  translation,  requiring  that  a  com¬ 
plement  be  chosen  that  remains  constant  is  to  restric¬ 
tive.  Bancilhon  and  Spyratos  [81]  prove  that  alternative 
(minimal)  complements  exist,  but  do  not  indicate  how 
to  generate  all  of  them.  They  also  do  not  show  how  to 
derive  a  view  update  translator  given  a  constant  com¬ 
plement.  We  suggest  that  further  work  consider  the 
generation  of  alternative  view  update  translations  with 
limited  effects  on  parts  of  the  database  not  appearing 
in  the  view. 
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